Repository navigation
fix(har): embed content that is not valid UTF-8 as base64 - #43524
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Hi, I'm the Playwright bot and I took a first look at the CI failures. 🟢 All failures are confirmed pre-existing flakesThe three real failures have each failed on unrelated revisions before. This PR at DetailsPre-existing flakes
Triaged by the Playwright bot - agent run |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Test results for "MCP"5154 passed, 614 skipped Merge workflow run. |
Test results for "tests 1"5 failed 3 flaky23574 passed, 713 skipped Merge workflow run. |
|
Hi, I'm the Playwright bot and I took a first look at the CI failures. 🟡 Two failures are uncertain; three are confirmed pre-existing flakesThis PR at DetailsOverall assessment The failures do not look caused by this PR. A clean rerun would resolve the two uncertain results; without one, the available history is not enough for a green verdict. Pre-existing flakes
Uncertain
Triaged by the Playwright bot - agent run |
content: 'embed', a body with a textual mime type was always stored as text, so a binary body served asapplication/javascriptwas decoded lossily and replayed with different bytes.isUtf8()), and as base64 otherwise.HA-113instead of extendingHA-021: it isfixmein WebKit, which decodes the body of a textual resource before Playwright gets it, so the original bytes are already lost there.Supersedes #43498: the same fallback, checked with
isUtf8()instead of re-encoding every textual body. ItsHA-113fails in WebKit for the reason above, and itsHA-114repeats whatHA-021already checks.Fixes #43493
Closes: #43498